Summary

The port of Loop's algorithm from LoopKit to the standalone LoopAlgorithm package dropped IntegralRetrospectiveCorrection's integral-correction limits — a safety guardrail that bounds the wound-up integral term so it cannot drive the forecast into over- or under-dosing. This PR restores that clamp.

It is a faithful restoration of the deployed-LoopKit formula (LoopKit/RetrospectiveCorrection/IntegralRetrospectiveCorrection.swift):

zeroTempEffect     = |ISF × basalRate|
positiveLimit      = min(max(glucose − rangeMax, 1× zeroTempEffect), 4× zeroTempEffect)
negativeLimit      = −max(10, glucose − rangeMin)
integralCorrection = clamp(integralCorrection, negativeLimit, positiveLimit)

• (+) limit — between 1× and 4× zeroTempEffect, larger the further BG is above the correction-range top (more room to correct a real high).
• (−) limit — at most ~(glucose − rangeMin) below target (10 mg/dL floor), capping over-suspension.

Design — backward compatible

The clamp needs ISF, scheduled basal rate, and correction range at the decision time. These are added as optional inputs to computeEffect(...) and generatePrediction(...):

• Any nil ⇒ legacy unclamped behavior, so the public API is unchanged for existing callers.
• LoopAlgorithm.run() passes input.target, so the deployed dosing path is clamped by default.
• Pure prediction (LoopPredictionInput carries no correction range) stays unclamped.
• StandardRetrospectiveCorrection accepts and ignores the inputs (no integral term to bound).

Tests

New cases in IntegralRetrospectiveCorrectionTests (reading integralCorrection directly):

• a wound-up positive integral is pinned to the positive limit;
• a wound-up negative integral is pinned to the negative limit;
• the clamp is inert when the integral is within limits (also confirms the change is non-breaking).

All 141 package tests pass.